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1.  INTRODUCTION 

A  transformation  is  needed  in  Human-Computer  Interface  (HCI)  to  accommodate  transformations  in 
information  availability,  computing  power,  and  changing  warfighter  roles.  The  HCI  paradigm  should 
be  transformed  from  system-centric  to  mission-centric,  and  the  HCI  should  be  decoupled  from 
individual  weapon/sensor/command  and  control  (C2)  systems  to  span  across  multiple  systems  to 
accomplish  mission  goals.  A  mission-centered  design  (MCD)  approach  can  achieve  the  needed 
revolution  in  HCI  via  transformations  in  three  areas:  (1)  HCI  Design  (how  the  HCI  supports  the 
warfighter);  (2)  HCI  Design  Process;  and  (3)  HCI  Software  and  Information  Management 
Infrastructure. 

A  Mission-Centered  Design  Consortium  (MCDC)  should  be  created  to  advance  each  of  these 
transformations  through  the  creation  of  open  standards  and  the  development/description  of  best 
practices. 


2.  WHY  TRANSFORM  HCI? 

“The  United  States  is  transitioning  from  an  industrial  age  to  an  information  age  military.  This 
transition  requires  transformation  in  warfighting  and  the  way  we  organize  to  support  the  warfighter.” 
(Department  of  Defense  [DoD]  Transformation  Planning  Guidance,  April  2003).  This  transformation 
is  necessary  to  maintain  our  overwhelming  military  advantage  by  exploiting  information  age 
technology  at  a  rate  faster  than  our  future  adversaries.  A  key  point  is  that  warfighters  exploit  the 
information  advantages,  not  be  overwhelmed  by  them.  One  lesson  learned  by  the  G2  of  the  1st 
Marine  Division  during  Operation  Iraqi  Freedom  was  the  inundation  of  information  and  data  that 
“had  little  bearing  on  their  mission  or  Intelligence  requirements.  Information  was  not  disseminated 
based  on  a  proactive  evaluation  of  what  supported  commanders  needed,  it  was  just  disseminated. 
There  seemed  to  be  little  thought  to  tailoring  information  to  specific  MSCs  [Military  Sealift 
Command]  or  develop  products  that  directly  anticipated  an  MSC  requirement.”  (report  attached  to 
memo  from  Commanding  General,  1st  Marine  Division,  dated  29  May  2003). 

Coupled  with  the  transition  from  platform-centric  to  network-centric  warfighting  is  a  budgetary 
demand  to  decrease  military  costs,  including  costs  related  to  crew  size.  Any  reduction  in  personnel 
cannot  be  made  at  the  expense  of  mission  performance.  HCI  design  plays  a  critical  role  in  enabling 
warfighter  performance,  reducing  training  time,  while  accommodating  increases  in  data  quantity  and 
complexity  across  a  broad  range  of  weapon  and  sensor  systems.  When  done  effectively  using 
standards  and  protocols,  HCI  design  supports  inter-service  and  multi-national  interoperability. 

HCI  transformation  is  timely  because  of  the  current  shift  toward  network-centric  warfare,  with 
changes  and  upgrades  to  legacy  systems  and  with  new  system  innovations.  HCI  is  as  much  about 
design  as  it  is  process.  The  following  specific  requirements  demand  that  a  transformation  in  HCI 
occur: 

•  Need  for  multi-tasking:  With  a  decrease  in  the  number  of  warfighters,  yet  an  increase  in  the 
number  of  weapon/sensor/C2  systems,  the  remaining  warfighters  of  the  future  will  manage 
more  systems  concurrently.  No  longer  can  the  military  afford  a  1 : 1  correspondence  of 
warfighter  to  each  mission  component  system. 

•  Need  for  increased  mission  cognizance:  The  warfighter  is  no  longer  dedicated  to  a  single 
system.  He/she  must  maintain  a  higher  level  of  cognizance  and  focus  on  mission  goals  that 
may  use  several  systems.  The  rapidity  of  warfare  requires  cognizance  at  all  levels  of 
command  authority  in  appropriate  detail. 
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•  Need  for  supervisory  control  of  systems:  There  will  be  an  increasing  reliance  on  computer 
systems  to  perform  procedural  functions  to  offload  the  remaining  warfighters.  With 
increasing  automation,  the  role  of  the  human  changes  from  a  data  collector/analyzer  to  a 
decision  maker  working  in  cooperation  with  automation. 

These  new  warfighter  roles  require  significant  changes  to  HCI  design  to  ensure  increased  efficiency 
(short  response  time,  no  errors,  and  minimal  training  time).  The  multi-tasked  supervisor  of  automated 
systems  must  maintain  a  higher  level  of  awareness  across  several  systems.  His/her  job  is  to  achieve 
an  operational  goal  that  may  span  the  information  and  capabilities  of  several  systems.  When  the 
operational  goal  is  well  defined,  the  HCI  must  assist  the  warfighter  by  maintaining  his/her  focus  on 
accomplishing  the  individual  tasks  to  achieve  these  goals.  The  warfighter’s  primary  interaction  with 
multiple  weapon/sensor/C2  systems  cannot  be  at  the  individual  system  level;  it  must  be  at  the 
operational  mission  goal  level.  Therefore,  the  primary  HCI  must  span  across  systems  yet  be  focused 
on  the  user’s  mission  goals.  The  warfighter  must  not  be  forced  to  interact  with  multiple  disparate 
HCIs  from  each  individual  system. 

An  efficient  military  HCI  then  is  one  that  seamlessly  buffers  the  warfighter  from  the  idiosyncrasies 
of  individual  weapon/sensor/C2  systems,  and  assists  him/her  in  focusing  on  the  mission  goals.  There 
can  no  longer  be  disparate,  inconsistent,  stove-piped  HCIs  that  force  the  warfighter  to  interact  with 
each  system  separately.  The  HCI  can  no  longer  belong  to  the  individual  weapon/sensor/C2  systems. 
The  HCI  of  the  future  is  a  system  of  its  own  dedicated  to  assisting  the  warfighter  in  accomplishing 
his  operational  goals  in  the  minimum  of  time,  with  minimal  errors,  and  requiring  minimal  training. 

Other  advantages  of  a  common  HCI  infrastructure  include: 

•  Consistent  HCI:  Display  styles  and  system  control  methods  are  reused. 

•  Evolvable:  Isolating  the  HCI  from  the  weapon/sensor/C2  systems  allows  a  separation  of 
growth  with  minimal  repercussions. 

•  Reusable  HCI  components:  Frequently  used  HCI  components  (e.g.,  maps,  symbols,  report 
formats,  decision  aids)  can  be  maintained  in  a  software  library.  These  components  can  be 
tailored  for  each  specific  task  or  as  defined  by  the  weapon/sensor/C2  system,  but  the  basic 
template  is  reusable. 

•  Reusable  watchstations:  Specialized  watchstations  will  become  less  common.  The  common 
HCI  system  will  reside  on  more  generic  watchstations  that  can  accommodate  multiple 
operational  goals  and  tasks. 

Recent  advancements  in  technology  make  this  separate  HCI  system  possible: 

•  Open  systems:  A  single  HCI  system  depends  on  its  ability  to  perform  data  input/output  for 
the  weapon/sensor/C2  systems.  The  data  therefore  must  be  readily  available  to  all  systems 
that  need  it. 

•  Standard  architectures:  Several  standardized  architectures  to  accommodate  open  systems 
have  been  developed,  e.g.,  Sun  J2EE®  (Java  2  Platform,  Enterprise  Edition),  Microsoft® 

.NET,  and  open-source,  web-based  architectures. 

•  Computing  power:  Enormous  quantities  of  data  become  available  when  weapon/sensor/C2 
systems  open  up  their  data  to  the  HCI  system.  These  data  must  be  intelligently  filtered  to 
avoid  overloading  the  warfighter.  When  the  warfighter’s  mission  is  known,  the  HCI  system 
can  intelligently  filter  the  data  to  focus  on  assisting  the  warfighter  in  accomplishing  his/her 
goal. 

We  must  continuously  evaluate  emerging  requirements,  coupled  with  advancements  in  technology,  to 
apply  smart  innovation  that  will  reap  rewards  in  improved  performance  and  cost  savings.  FORCEnet 
is  one  such  concept  meant  to  revolutionize  Navy  system  interconnectivity.  The  time  is  right  for  a 
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revolution  in  HCI  as  well.  An  HCI  system  overarching  across  multiple  weapon/sensor/C2  systems 
using  the  interconnectivity  provided  by  FORCEnet  is  a  perfect  match  for  this  vision  of  future  Navy 
capability. 

In  this  document,  we  discuss  the  means  to  achieve  these  requirements,  which  then  forms  the  basis  for 
transformation  in  performance  and  operations.  HCI  alone  cannot  achieve  transformation;  but  when 
done  poorly  or  without  regard  to  human  capabilities  and  limitations,  it  can  become  a  block  to  other 
technology  or  process  advances.  We  present  the  notion  that  MCD  for  HCI,  when  coupled  with  a 
process  that  works  in  DoD  design  and  procurement,  together  with  cost-cutting  and  enabling  software 
methods,  enables  a  jump  from  today  to  a  transformed  Navy  human-system  capability. 

3.  HCI  TRANSFORMATION  GOALS 

HCI  transformation  is  about  design  requirements  and  results,  together  with  a  process  for  engineering 
development  that  includes  legacy  and  innovative  system  components.  The  HCI  design  paradigm 
should  be  transformed  from  system-centric  to  mission-centric,  and  the  HCI  should  be  separated  from 
individual  weapon/sensor/C2  systems  to  span  across  multiple  systems  to  accomplish  mission  goals. 
An  MCD  approach  can  achieve  the  needed  revolution  in  HCI  via  transformations  in  three  areas: 

•  HCI  Design  and  Requirements  (how  the  HCI  supports  the  warfighter) 

•  HCI  Design  Process 

•  HCI  Software  and  Information  Management  Infrastructure 

3.1  MISSION-CENTERED  HCI  DESIGN 

HCI  encompasses  not  only  display  format,  but  content,  context,  management,  and  delivery.  Today's 
design  is  most  often  data  driven  and  function  centered.  Designers  place  data  into  windows  by  data 
type — tactical  maps,  tabular  data,  multitudes  of  status  displays.  In  recent  research  (Osga  et  al.,  2002), 
we  have  defined  key  cognitive  requirements  for  warfighter  support  throughout  the  entire  decision 
process  and  across  a  multitude  of  tasks.  Mission  tasks  require  analysis,  synthesis,  and  combination  of 
data  types  to  provide  for  mission  task  solutions.  Designers  leave  much  of  the  manual  labor  to  the 
warfighters  at  all  levels  of  tactical  and  operational  levels.  Key  facets  of  an  MCD  in  comparison  to 
today’s  approach  are  shown  in  Table  1.  The  reader  is  referred  to  other  papers  for  further  details  on 
these  design  qualities  (Osga  2003a,  2003b). 

An  MCD  approach  to  HCI  centers  on  supporting  the  mission  goals  and  interim  mission  products  that 
the  human  and  system  must  produce.  This  approach  provides  explicit  mission  and  task  visualization, 
increases  support  for  all  cognitive  task  phases,  visually  links  information  across  tactical  maps  and 
mission  plans  and  solutions,  and  focuses  software  and  design  to  prepare  high-quality  mission  task 
products.  Products  may  be  as  broad  as  a  coordinated  strike  plan  or  as  focused  as  an  individual  air 
defense  track  update  report.  The  warfighter  is  then  “freed”  from  complex  manual  labor  at  all  levels 
and  can  become  a  strategic  thinker,  planner,  and  manager  of  mission  tasks — the  desired  roles  for 
warfighters  in  a  transformed  Navy.  The  HCI  design  directly  focuses  on  the  tasks  that  must  be 
accomplished  to  achieve  a  mission  goal,  rather  than  on  an  individual  system’s  functions.  The  entire 
mission  is  supported  via  a  Mission-Specific  Presentation  Layer  common  across  multiple  systems.  All 
phases  of  the  warfighter’s  cognitive  and  visual  work  are  supported  by  the  HCI  software:  initiation, 
orientation,  decision,  product  development  and  delivery,  confirmation,  and  transition. 
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Table  1.  Comparison  of  future  HCI  goals  with  today’s  capabilities. 


MCD  HCI  Transformation  Goals 

Comparison  with  Today 

Explicit  mission  and  task 
visualization. 

Mission  process  visualization  ignored  in 
design. 

Support  all  cognitive  task  phases: 
initiation,  orientation,  decision, 
execution,  confirmation,  transition. 

Support  missing  for  task  initiation,  often  with 
poor  orientation,  complex  execution,  poor 
confirmation,  and  no  support  for  transition. 

Support  work  management. 

Support  is  non-existent  -  relies  on  training 
community  and  missing  in  design. 

Visually  link  information. 

Limited  visual  linking  -  not  in  a  task  context. 

Prepare  high  quality  mission  task 
products. 

Data  dumps  in  windows  by  data  types  -  not 
product  oriented. 

Build  for  evolution  over  time 

Hard-wired,  stove-piped  individual  HCI  for 
every  subsystem  with  costly  evolution. 

An  HCI  produced  through  MCD  provides  explicit  mission  and  task  support,  intelligently  pulling 
task-relevant  information  from  multiple  sources.  The  HCI  and  supporting  infrastructure  anticipate  the 
needs  of  the  warfighter,  presenting  only  relevant  information  to  support  his/her  task,  while  also 
presenting  options  and  product  candidates  for  the  warfighter  to  chose  from.  The  warfighter  remains 
the  decision  maker;  the  software  becomes  his/her  executive  assistant  performing  the  menial  tasks  that 
computers  do  well.  The  warfighter  maintains  the  flexibility  to  bypass  the  recommendations  made  by 
the  assistant  and  to  deviate  from  preconceived  software-assisted  tasks  that  may  not  fit  unanticipated 
situations.  But  for  all  mission  tasks  that  can  be  anticipated,  the  HCI  and  supporting  infrastructure  are 
fine-tuned  to  minimize  warfighter  workload  and  errors  while  maximizing  decision  speed  and  quality. 

MCD  HCI  also  crosses  the  boundaries  of  multiple  systems  and  mission  phases.  The  emphasis  is  on 
the  integration  of  warfighter  and  mission(s),  working  in  harmony  and  synchronization  from  pre¬ 
planning,  through  planning  and  execution,  from  tactical  through  operational  to  strategic  mission 
goals.  This  approach  is  in  contrast  to  working  from  sensors  to  databases  and  networks  ending  up  with 
reams  of  data  dumped  into  windows  with  a  huge  training  and  warfighter  workload  burden  to  turn 
these  incomplete  results  into  mission  products.  The  methodology  exists  in  structured  scientific 
methods  within  the  domain  of  Human  Factors  Engineering,  using  a  Cognitive  Work  Analysis 
(Vincente,  1999,  2002),  which  focuses  system  requirements  on  supporting  the  warfighter  by 
performing  a  Work  Domain  Analysis  (WDA),  leading  to  high-quality  requirements  and  design  that  is 
developed  and  tested  using  structured  prototyping  and  usability  testing. 

This  MCD  approach  has  been  successfully  demonstrated  within  the  Air  Defense  Warfare  mission 
domain  (Osga  et  al.,  2002)  and  is  currently  being  applied  to  Land  Attack  Warfare  (Kellmeyer  et  al 
2002)  and  the  DD(X)  program. 

3.2  HCI  DESIGN  PROCESS 

MCD  requires  careful  analysis  of  mission  processes  and  workflows.  VADM  Albert  Konetzni, 

Deputy  Commander  and  Chief  of  Staff  for  the  Atlantic  Fleet,  has  stated  that  the  military  “has  largely 
abandoned  operations  analysis.... A  better  path  would  be  one  in  which  proposals  for  innovation  are 
studied  analytically  and  developed  with  a  ‘complete  plan’ — including  concept  of  operations,  training, 
and  maintenance — before  we  throw  these  things  on  our  ships”  (speech  to  the  Armed  Forces 
Communications  &  Electronics  Association  (AFCEA)  Transformation  TechNet  2003  conference. 
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13  May  2003).  An  HCI  design  process  must  not  only  perform  the  up-front  cognitive  work  analysis 
needed  to  ensure  support  for  the  warfighter,  but  must  include  expert  warfighters  early  and 
continuously  throughout  the  analysis,  design,  and  development  of  the  HCI. 

The  products  from  a  representative  MCD  process  are  shown  in  Figure  1.  There  are  four  basic  phases 
in  the  MCD  process:  Analysis,  Design,  Implementation,  and  Development.  Each  box  in  Figure  1 
represents  a  product  produced  during  one  phase  of  the  process  and  is  color-coded  to  signify  which 
process  phase  produced  it. 


Figure  1.  Representation  of  HCI  design  and  test  process. 


3.2.1  Analysis 

The  Analysis  Phase  focuses  on  understanding  the  warfighters,  their  mission,  the  environment  they 
work  within,  and  the  tasks  they  must  perform  to  achieve  their  mission.  The  goal  of  the  Analysis 
Phase  is  to  develop  Use  Cases  that  define  the  warfighter  mission  goals.  An  Activity  Diagram  details 
the  task  steps,  task  allocation  (who  does  the  task),  decision  points,  information  requirements,  and 
major  task  products.  Existing  Performance  Metrics  are  examined,  and  may  be  modified.  These 
metrics  will  be  used  in  the  evaluation  of  the  design.  The  primary  mechanisms  used  to  obtain  these 
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Analysis  Phase  Products  include  cognitive  work  analysis,  task  analysis,  field  studies,  and  user  focus 
groups. 

3.2.2  Design 

The  Design  Phase  focuses  on  developing  a  design  that  allows  the  warfighter  to  perform  each  of  the 
Use  Cases  identified  during  the  Analysis  Phase.  This  phase  begins  by  identifying  the  HCI 
requirements  for  decision  making,  information  presentation,  process  monitoring,  collaboration,  etc. 
An  investment  in  research  and  development  (R&D)  can  refine  design  concepts  specific  to  mission 
domains  to  reduce  risk  during  formal  implementation.  Re-useable  and  generalized  HCI  design 
patterns  (decision  support  templates)  are  refined  into  task-specific  display  components  based  on  the 
specific  task  requirements.  For  example,  a  general  mission  response  plan  template  may  be  refined 
into  a  time,  range,  or  step-based  format  depending  on  the  type  of  mission  task  (see  Osga,  2003b). 
Specific  task  products  are  formulated  for  each  important  step  or  phase  of  the  mission  process.  Then 
cognitive  walkthrough  and  design  sessions  are  required  to  customize  these  displays  to  support  the 
defined  Use  Cases.  Low-fidelity  prototypes  are  used  to  evaluate  initial  designs  via  user  (warfighter) 
focus  groups,  heuristic  evaluations,  and  usability  testing  (with  warfighters).  The  input  from  these 
evaluations  is  then  compiled  into  a  draft  User  Interface  (UI)  specification  used  to  produce  a  high- 
fidelity  prototype.  These  higher  fidelity,  dynamic  prototypes  can  be  used  to  evaluate  the  aspect  of 
time  and  how  the  design  fits  within  the  general  UI  framework.  The  defined  Performance  Metrics  are 
used  to  evaluate  the  high-fidelity  prototype  in  another  round  of  usability  testing.  The  results  are 
factored  to  produce  a  final  design  that  is  documented  as  a  User  Interface  specification  for 
implementation.  The  warfighter  is  incorporated  early  into  the  design  and  testing  process  using  this 
approach  of  iterative  design  and  usability  testing.  This  improves  the  HCI  product  quality,  reduces 
risk  for  product  acceptance,  and  requires  fewer  modifications  to  future  software  builds. 

3.2.3  Design  Reference  Implementation 

The  goal  of  the  Implementation  Phase  is  to  model  the  defined  UI  specifications  and  the  decision, 
information,  UI,  and  task  requirements  into  software  design.  Frequent  discussions  are  needed 
between  the  software  designers  and  the  HCI  designers  to  ensure  thorough  understanding  and 
intentions  from  the  Design  Phase.  The  software  designers  also  evaluate  adapter  requirements  for 
legacy  systems  and  propose  architectures  for  new  systems  in  this  phase.  The  Implementation  Phase 
results  in  a  reference  implementation  that  needs  to  be  subjected  to  usability  testing  as  soon  as 
possible  to  ensure  that  requirements  and  specifications  had  been  interpreted  correctly.  An  initial 
means  for  confirming  successful  interpretation  is  a  heuristic  evaluation. 

3.2.4  Development 

The  Development  Phase  is  the  actual  coding  of  the  UI  design,  and  may  be  done  by  a  different  team 
(e.g.,  a  primary  contractor)  than  the  team  that  executed  the  analysis,  design,  and  implementation 
phases.  Users  (warfighters)  should  be  involved  as  frequently  as  possible  to  evaluate  the  final  product. 
Once  fielded,  a  mechanism  to  collect  user  feedback  should  be  introduced  and  field  studies  conducted 
to  observe  how  users  are  actually  employing  the  fielded  system.  These  observations  should  be 
documented  and  provided  as  inputs  to  the  next  Analysis  Phase. 

3.3  MCD  HCI  INFORMATION  MANAGEMENT  AND  ARCHITECTURE 

Mission  requirements  and  processes  change  over  time.  MCD  requires  software  architectures  that  are 
amenable  toward  changing  task  conditions.  Hence,  we  should  build  using  architectures  that  allow  for 
new  task  support  and  reduce  cost  and  development  time.  Fortunately,  best  practices  in  modem 
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Web-based  computing  afford  designs  with  a  separate  HCI  presentation  layer,  which  can  use  adapters 
to  access  task-relevant  information  from  legacy  systems.  This  allows  us  to  transition  from  today  and 
add  new  capabilities  for  tomorrow  in  a  common  approach. 

To  truly  revolutionize  toward  an  MCD,  we  need  to  develop  a  standardized  terminology  and  modeling 
language  for  representing  missions  and  their  interrelated  tasks.  This  would  involve  the  development 
of  a  standardized  markup  language  for  tagging  task-relevant  information  so  that  systems  can  publish 
data  according  to  the  standard,  and  mission-centered  HCIs  can  then  subscribe  to  it.  Currently,  there 
may  be  several  Navy  mission  domains  each  needing  the  same  type  of  task  products  and  decision 
support,  yet  each  is  paying  for  engineering  development  and  production.  They  could  be  making 
minor  changes  to  common  aids  at  much  reduced  corporate  Navy  cost.  As  naval  capabilities  evolve 
and  grow  with  new  sensors,  weapons,  and  joint  collaboration,  redundant  software  changes  in  HCI 
across  system  domains  are  minimized  and  new  decision  support  capabilities  can  transition  from  R&D 
to  field  use  in  a  minimized  time.  Within  this  open  architecture,  information  must  flow  freely  from 
source  to  use.  Barriers  and  stovepipes  within  Navy  and  across  joint  mission  domains  must  be 
reduced.  The  goals  of  FORCEnet  can  support  these  MCD  requirements. 

Figure  2  shows  a  candidate  MCD  architecture  deployed  as  a  distributed,  task  management  enterprise 
application.  The  presentation  and  application  tiers  connect  to  corporate  information  management 
systems  via  Web  Services  and  custom  adapters.  Presentation  clients  are  both  thin  and  thick,  as 
dictated  by  HCI  autolinking  requirements.  Thin  clients  can  also  run  on  laptops  and  other  systems 
outside  the  watchstation  cluster.  This  means,  for  example,  that  currently  unsupported  (by  a 
watchstation)  warfighters  have  access  to  mission  planning  and  weapon  control  system  information. 
The  automated  assistance  of  task  and  workload  management  is  implemented  within  an  application 
server  that  supports  a  team  of  warfighters.  Mission  tasks  are  triggered  by  external  events  such  as  a 
call-for-fire  or  hostile  track  detection  by  the  legacy  system.  Tasks  execute  on  the  clients  (presentation 
tiers),  mediating  the  presentation  of  data,  status,  and  draft  products  in  the  HCI  to  the  warfighter.  The 
connection  tier  “talks”  native  protocol  on  the  legacy  side,  and  standard  Web  Services  on  the  task 
management  side.  The  legacy  system’s  public  functions  have  been  exposed  through  a  variety  of 
means,  including  native  application  programming  interfaces  (APIs)  and  Common  Object  Request 
Broker  Architecture  (CORBA). 
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Figure  2.  Conceptual  model  of  a  task  management  system  deployed  in  an  enterprise  architecture. 


4.  HOW  TO  TRANSFORM  HCI 

A  Mission-Centered  Design  Consortium  (MCDC)  should  be  created  to  advance  each  of  the  HCI- 
related  transformations  (design,  process,  software,  and  information  infrastructure)  through  the 
creation  of  open  standards  and  the  development/description  of  best  practices.  The  goal  is  to  nurture 
active  participation  in  a  DoD-wide  consortium  modeled  on  civilian  standards  definition 
organizations. 

Currently,  individual  Program  Offices  make  decisions  on  HCI  related  to  procurement, 
administration,  quality  control,  configuration  management,  etc.  Commonality  occurs  only  to  the 
degree  that  standards  such  as  DII/COE  (Defense  Information  Infrastructure/Common  Operating 
Environment)  are  used  or  enforced.  To  achieve  significant  performance  improvement  and  impact  on 
mission  success,  the  notion  of  HCI  must  be  expanded  beyond  the  bounds  of  individual  systems  and 
their  associated  Program  Offices.  “We  must  change  from  an  approach  that  is  optimized  by  program 
and  platform  to  one  that  can  solve  the  challenges  of  integrated  systems  that  cross  many  platforms  and 
functions”  (Navy  message  from  Assistant  Secretary  of  the  Navy,  Research,  Development  and 
Acquisition  (ASN  RDA)  dated  1 1  Oct  2002  on  ASN  RDA  Realignment). 

The  design  notion  of  MCD  embodies  a  connected  set  of  HCI  models  or  design  views.  There  is  no  one 
single  “ownership”  issue  but,  instead,  multiple  issues  of  sharing  design  knowledge  and  design 
practice  at  each  level  of  the  design  view.  There  may  be  Central  Ownership  of  agreed-upon  standards 
and  the  HCI  infrastructures,  but  quality  control  and  content  for  specific  warfare  and  task-specific 
components  and  their  content  should  remain  the  responsibility  of  individual  Program  Offices.  The 
net  result  is  that  centrally  owned  tools,  standards,  and  infrastructure  allow  for  an  easier  “plug  and 
play”  method  for  assembling  innovative  decision  aids  and  HCI  tools.  The  ultimate  goal  for  any  HCI 


8 


design  business  strategy  must  be  to  bring  the  best  result  to  the  warfighter  with  the  most  efficient 
design  process. 

The  following  qualities  should  exist  in  future  HCI  design  practice: 

1 .  Standards  for  information  sharing  and  availability.  Standards  are  useful  to  allow  connectivity 
and  information  interchange  among  systems  and  components.  This  is  required  for  successful 
inter-Navy  and  joint  collaboration  through  electronic  (vice  voice)  means.  Within  warfare 
domains  (air  strike,  land  attack,  mine  warfare,  undersea  warfare,  etc.),  information  should  be 
posted  and  shared  in  a  seamless  manner.  Information  should  be  made  available  to  other 
domains  as  security  levels  allow.  Collectors  and  producers  of  data  (e.g.,  sensors,  intel)  should 
be  required  to  post  data  in  a  format  that  is  accessible  by  information  databases  and  decision 
support  tools.  The  format  for  HCI-related  information  should  be  established  by  the  MCDC. 

2.  Common  warfare  decision  support  tools.  There  are  common  cognitive  decision-making 
requirements  across  mission  domains,  e.g.,  warfighters  need  to  see  the  mission  plan  as  well 
as  any  delays  or  roadblocks  relative  to  the  plan.  The  need  exists  to  visualize  current  and 
future  events.  There  could  be  a  central  ownership  of  various  decision  support  tools,  with 
variations  available  to  Program  Offices  for  tailoring  to  their  specific  domain.  For  example, 
there  could  be  time-,  range-,  and  step-based  formats  for  representing  ship  doctrine/processes 
for  each  mission  in  a  decision  support  tool  called  the  Response  Planning  Manager  (RPM) 
(Osga  et  al  2002).  (The  notion  and  requirements  for  the  RPM  were  derived  from  Office  of 
Naval  Research  (ONR)-sponsored  6.2  and  6.3  research.)  In  this  manner,  a  Program  Office 
preparing  a  new  RPM  or  updating  a  previous  RPM  would  save  cost  and  time  while  focusing 
on  the  specific  RPM  requirements  for  their  mission  domain. 

3.  Best-practice  information  architectures.  The  information  architecture  supporting  the  HCI — 
thus  supplying  information  to  decision  aids — should  be  standardized  such  that  decision  aid 
developers  can  integrate  updated  tools  and  techniques  into  an  open  architecture.  Management 
of  the  architecture  should  be  within  an  enterprise  or  domain  such  as  a  major  systems 
command  (e.g.,  Space  and  Naval  Warfare  Systems  Command,  Naval  Sea  Systems 
Command)  but  certainly  could  be  broader  (all  combat  and  C4I  systems  [command,  control, 
communications,  computers  and  intelligence  systems]).  Any  information  support  architecture 
should  support  the  premise  of  HCI  Design  Practice  item  #  I  above,  that  information  can  be 
shared  and  accessible  by  decision  support  tools  across  domains.  The  architecture  should  be 
open  and  shared  and  a  consensus  of  the  government  and  industry  consortium  (MCDC).  This 
would  result  in  the  incorporation  of  best  ideas  and  improvements,  with  shared  benefit  for  all 
developers  and  users.  The  MCDC  should  define  the  architectural  system  structures,  their 
components,  relationships,  and  the  principles  and  guidelines  governing  their  design  most 
appropriate  to  MCD. 

4.  Proprietary  and  non-proprietary  components.  Proprietary  components  should  be  minimized, 
though  they  may  be  necessary  at  some  level  to  foster  competition.  Competition  is  healthy  for 
innovation  and  new  ideas,  while  proprietary  components  can  impede  innovation  and  progress 
when  an  established  company  has  little  motivation  for  change  or  risk.  For  HCI,  competition 
among  decision  support  tools  could  be  healthy  and  foster  design  innovation.  In  the  example 
above,  an  improved  RPM  would  benefit  fleet  operators.  Thus,  developers  of  decision  tools 
such  as  the  RPM  may  be  allowed  to  hold  their  design  qualities  as  proprietary  to  protect 
intellectual  property.  However,  the  infrastructure  and  integration  standards  into  which  the 
decision  tool  interacts  and  connects  to  the  broader  tool-base  should  be  open  and  shared.  Thus, 
it  should  be  easy  for  a  developer  who  desires  to  create  a  new  RPM  to  inspect  the  MCDC 
requirements  and  use  the  integration  specifications  to  develop  a  new  version  of  the  RPM  tool. 
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A  spiral  development  program  should  be  fostered  where  anyone  at  any  time  can  present  an 
improved  design  for  a  decision  aid  to  support  iterative  design  improvements  with  faster 
introduction  to  the  fleet. 

5.  Standards  for  decision  tools  plug  and  plav.  The  MCDC  should  establish  and  control  the 
standards  for  how  decision  support  tools  plug  and  play  in  the  common  HCI  architecture.  The 
standards  should  be  based  on  Navy  stakeholders  in  each  mission  area  producing  a  method 
that  supports  the  performance  requirements  for  each  warfare  domain.  If  a  single  standard  or 
approach  cannot  be  identified,  tiered  approaches  based  on  cost  and  performance  may  be 
selected. 

6.  Task  Library  and  Definition.  Ultimately,  an  MCD  is  based  on  a  mission  process  and  concept 
of  operations  (CONOPS),  and  identification  of  tasks  and  products  within  the  defined 
operational  concepts.  Naval  Warfare  Doctrine  Command  (NWDC)  has  recently  been  in  the 
lead  in  the  development  of  Navy  Task  Lists,  which  are  related  to  Mission  Essential  Task 
Lists  and  Joint  lists.  These  lists  must  be  improved  and  extended  down  to  an  operational  and 
tactical  level  to  support  MCD  at  the  individual  weapon  and  sensor  system  level.  The  tasks 
must  mature  beyond  title  or  task  name  and  be  subjected  to  a  rigorous  work-domain  analysis 
and/or  cognitive  task  analysis.  This  would  be  a  large  undertaking  likely  beyond  the  capacity 
of  NWDC  and  should  be  shared  by  the  warfare  specific  domain  Program  Offices.  The 
resulting  task  identification  and  cognitive  requirements  provide  guidance  to  developers  and 
designers  of  decision  support  systems  for  those  tasks.  Information  should  be  managed  and 
stored  by  NWDC  or  possible  ASD  (RDA)  CHENG  (Assistant  Secretary  of  the  Navy  for 
Research,  Development  and  Acquisition,  Chief  Engineer)  personnel  and  available  as  needed 
by  developers.  Common  task  characteristics  can  be  extracted  to  develop  a  standard,  template 
definition  of  a  warfighter  task.  The  MCDC  would  determine  the  best  methodologies  for 
software  modeling  of  the  generic  task  that  could  then  be  reused  in  all  task  implementations. 
The  MCDC  would  also  resolve  ambiguities  in  terminology  such  as  the  relationships  between 
tasks,  subtasks,  workflow,  work  items,  task  steps,  etc. 

7.  HCI  Testing  Standards.  The  government  should  set  standards  for  HCI  usability  testing  such 
that  developers  know  precisely  what  level  of  test  is  required  to  ensure  that  usability  test  goals 
are  met  and  represented  in  the  test  results.  These  standards  should  be  held  by  a  central  Navy¬ 
wide  policy  command  such  as  Office  of  the  Chief  of  Naval  Operations  (OPNAV)  N-125 
H.S.I.  Division.  The  important  points  of  usability  testing  are  that  different  levels  of  fidelity 
are  allowed  (ranging  from  paper  to  full  mockup)  and  that  it  should  occur  early  in  the  design 
process  and  iterate  throughout.  The  MCDC  can  also  establish  a  set  of  target  performance 
metrics  and  specifications  that  a  system  based  on  MCD  must  achieve. 

Difficulties  that  typically  impede  inter-program  cooperation  and  advancement  on  HCI-related 
standards  often  stem  from  the  fact  that  no  two  programs  are  ever  in  the  exact  same  stage  of 
development.  Some  programs  are  more  “open”  and  others  have  many  proprietary  or  closed 
components.  Also,  budgets  may  scale  up  or  down  during  any  given  fiscal  year  within  or  across 
warfare  domains.  Thus,  a  dual  approach  to  ownership  of  HCI  components  could  address  legacy 
system  upgrades  and  a  fully  “open”  approach.  The  legacy  approach  may  include  standards  and 
available  methods  for  connection  of  legacy  components  with  advanced  HCI  software  layers.  This 
approach  might  also  contain  funds  to  allow  legacy  systems  to  publish  information  as  electronically 
available  to  decision  aids.  The  MCDC  would  assist  in  defining  standard  technical  approaches,  data 
definitions,  and  guidelines  for  migrating  application-centric  legacy  systems  to  accommodate  mission¬ 
centric  HCI.  The  open  approach  should  develop  the  best-practice  approaches  based  on  the  MCDC. 
The  result  will  be  a  targeted  architecture  and  development  framework  that  new  components  could 
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adhere  to,  and  older  components  could  migrate  toward.  The  design  must  be  continuously  updated  and 
revisited  such  that  it  does  not  become  obsolete  or  outdated  as  other  standards  and  methods  evolve 
over  time.  ! 

Table  2  summarizes  the  components  of  HCI  and  how  “ownership”  may  be  employed  for  each 
component.  In  each  case,  advancement  and  innovation  must  not  be  impeded  by  the  owner  or 
stakeholders,  but  must  be  fostered  to  keep  the  Fleet  at  the  cutting  edge  of  technology  and 
performance. 

Decision  aids  and  their  products  are  directly  affected  by  the  quality  and  timeliness  of  information 
available  to  algorithms  and  methods.  Successful  HCI  will  occur  when  information  is  collected  at  a 
source  unrelated  to  the  decision  aid,  but  made  available  to  the  aid  through  the  use  of  standards  that 
allow  the  information  to  be  posted  and  then  used  by  the  aid.  Thus,  each  aid  will  be  empowered  by  a 
far  greater  number  of  sources  of  information  than  previously  available.  Issues  of  quality  and 
reliability  exist,  but  they  are  solved  or  allow  for  user  inspection,  vs.  the  greater  evil  of  having  no 
information  available  or  having  it  arrive  too  late  to  support  key  mission  decisions  or  events. 

HCI  is  a  cooperative  and  shared  design  problem  that  transcends  information  sources  and  storage  and 
creates  opportunities  for  reducing  cost  of  design,  test,  and  delivery  within  and  across  warfare 
domains.  Greater  capability  and  support  can  be  brought  to  the  warfighter  much  sooner  than  HCI 
development  efforts  within  a  single  Program  Office  might  allow. 


Table  2.  HCI  architecture  components  by  organization,  status,  and  use. 


HCI 

Component/Standard 

Ownership 

Organizations 

Using 

Advancement 

Current  Status 

Presentation  HCI 
patterns  look  and 
feel 

MCDC 

Government, 
industry,  labs 

Performance 
based  for 
speed, 

accuracy,  and 
training 

Dll/COE,  DISA, 
industry  best 
practice 

Presentation 
decision  aid  and 
support  tools 

Specific 

programs 

Warfare 
domains,  labs, 
and  industry 

Innovation 
fostered 
through  R&D 

No  common 
design  themes 

Information  support 
structure 

Specific 

programs 

Government, 
industry,  labs 

Open  and 
available  where 
and  when 
needed  by  DAs 

Stove-pipes, 
gaps  within 
mission 
domains. 

Business  logic  of 
individual  systems 

Specific 

programs 

Government, 
industry,  labs 

Tested  and 
reliable  and 
(possible)  re¬ 
usable  across 
domains 

Individualized 
by  each  system 
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5.  SUMMARY 

We  have  identified  three  key  strategy  areas  for  a  revolution  in  Navy  HCI  to  enable  the  vision  of 
SeaPower  21  of  improved  effectiveness,  faster  speed  to  capability,  reduced  manning,  and  reduced 
cost.  These  transformations  are  in  MCD  HCI  Design,  HCI  Design  Process,  and  HCI  Software  and 
Information  Management  Architecture.  Fortunately,  our  Navy,  through  ONR  sponsorship,  has  the 
benefit  of  years  of  HCI  research  in  support  of  these  transformations.  The  results  are  now 
transitioning  within  focused  mission  domains  through  Future  Naval  Capability  programs,  and 
provide  a  wealth  of  requirements  and  guidance  on  which  to  launch  a  revolution  in  naval  HCI  process 
and  design.  The  ingredients  needed  now  are  the  will,  resources,  and  a  teamwork  commitment  to 
excellence  across  a  transformed  Navy  HCI. 
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